-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding fido appid extension #229
Conversation
Please rename extension to webauthn_appid as it is used by other FIDO spec families as well. |
:: A single UTF-8 encoded string specifying a FIDO U2F |appId|. | ||
|
||
: Client processing | ||
:: AppId validation (as defined by the FIDO U2F specification). If valid, the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need a real reference for this. Please contribute to http://www.specref.org/ or add to the biblio block at the end of the Bikeshed source (it's also in SpecRef format).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a PR in specref: tobie/specref#298. Feel free to upvote.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rlin1, thanks for the suggestion! Done. |
Closes Issue #216
@vijaybh, any idea how to update travic cl's bikeshed to pull in the new biblio data? |
/cc @tabatkins (--sorry, thought this was about the api on csswg.org.) |
You should run 'bikeshed update' after install to get the latest spec/biblio data. Alternatively you can use the online bikeshed at https://api.csswg.org/bikeshed (which is always up to date) |
@leshi: Can you do an update of the bikeshed data in the repo (in It'd be something like:
and then test, and commit the changeset. |
|appId| [[FIDO-APPID]] to overwrite the otherwise computed |rpId|. | ||
|
||
: Extension identifier | ||
:: `webauthn_appid` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if fido_appid would be a more descriptive name here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that would be fine with me, tho note that @rlin1 suggested webauthn_appid
in #229 (comment) (rather than webauthn_u2f-appid
-- i think fido_appid
meets @rlin1 's goal (?). Also the section title is "FIDO AppId".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also: s/[RP]s/[RPS]/;
Also, "Authenticator" and "Client", in prose text should be lower case (except at beginning of sentence).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done on renaming webauthn_appid
to fido_appid
Done on correcting capitalization of Authenticator
and Client
: Client processing | ||
:: The Client must perform AppId validation (as defined by [[FIDO-APPID]]). If | ||
valid, the value of |rpId| for all Client processing should be replaced by | ||
the specified |appId|. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if rpId is also specified in the options? Should this win, or should the call just error out? (FWIW I'm in favor of erroring out by throwing an exception - it is a programming error and the code should never be written that way.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, i can agree with the approach Vijay suggests -- though the spec ought to explicitly indicate that rpId/appId is an "either/or", both in this extension section, and in the section on dictionary AssertionOptions
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added language about it being an error to explicitly specify the rpId if using this extension.
Also added language to say that it is an error to use this extension outside the scope of getAssertion()
: Client argument | ||
:: A single UTF-8 encoded string specifying a FIDO |appId|. | ||
|
||
: Client processing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stylistically, I wonder if this would be better written as "Replace step 3 in section foo with the following: ..." so this would be very clear. Would also help with defining error behavior as below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, it would be good to be very explicit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have made this change as requested.
## FIDO AppId ## {#extension-appid} | ||
|
||
This authentication extension allows [RP]s who have previously registered an | ||
Authentication using the legacy FIDO JavaScript APIs to communicate with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"registered an Authentication" sounds weird. Maybe "registered a credential"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion. Wording improved.
following procedure: The client uses the value of |fido_appid| to perform | ||
the AppId validation procedure (as defined by [[FIDO-APPID]]). If valid, | ||
the value of |rpId| for all client processing should be replaced by the | ||
value of |fido_appid|. It is an application error to both use this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be better to make the error explicit and move it to the beginning of the procedure. Something like "If {{AssertionOptions/rpId}} is present, reject promise with a DOMException whose name is "NotAllowedError", and terminate this algorithm. Otherwise, ..."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Added two editorial suggestions. Other than that this LGTM. |
Looks fine to me. |
Closes Issue #216